A database system may use plans to execute operations relating to the data stored in that database's data storage spaces (e.g., relational tables). Plans may be formulated in response to requests for the database system to perform operations such as storing, retrieving, and manipulating data. These requests may come in a variety of forms known within the art, including structured query language (SQL) and data definition language (DDL) statements and blocks. Techniques for determining plans to execute requested database operations are well-known within the art.
Plans may be converted into compiled representations before execution. A compiled representation of a plan is an internal representation that may be quickly executed by the database system. For example, the compiled representation may be in a language more native to the computer or operating system on which the database system is running. Alternatively, the compiled representation may be in an optimized form whereby the database system may execute the plan with minimal additional lookups or input. A compiled representation is also known within the art as a program unit or cursor.
Cursors may be maintained for reuse. If, after creating a cursor for a plan, a database system needs to perform the same plan additional times, the database system may locate the cursor that the database system created the first time and execute the plan using that cursor instead of compiling a new cursor. For example, if a database system receives the SQL statement SELECT * FROM tab1 multiple times, the database system may use the same cursor to execute the plan indicated by the statement each time. As is known within the art, parameters may be used to create more generalized cursors, thereby increasing those cursors' reuse potential. For example, the plan described by the statement SELECT name FROM tab1 WHERE id=10 could be executed by a cursor for the plan SELECT name FROM tab1 WHERE id=%1, where the value of the %1 parameter is 10. Since cursor compilation requires a relatively large amount of time and memory, a database system can greatly increase efficiency by maintaining cursors for reuse.
Cursors may utilize metadata describing the data storage spaces to which those cursors may require access. This metadata may contain, for example, segment addresses for each partition in the data storage space. Metadata can further increase efficiency by reducing or eliminating the amount of time that a cursor must spend looking up information about data storage spaces.
Some database systems store private copies of the metadata needed by each cursor inside the cursors themselves. This technique wastes memory resources; each cursor that accesses a particular data storage space may store that cursor's own identical copy of the metadata for that storage space. Since the size of metadata increases proportionally with the number of partitions in a data storage space, the resource waste resulting from metadata duplication is even further compounded for data storage spaces with many partitions.
To overcome this problem, some database systems store shared copies of metadata external to the cursors. When the cursors are compiled, those cursors are linked in the compiled code to a shared copy of the metadata that those cursors require. Many cursors may be linked to the same shared copy of metadata. Such a technique is described in U.S. application Pub. No. 20060004755, entitled “System for allowing object metadata to be shared between cursors for concurrent read write access,” filed on May 13, 2005, which is hereby incorporated by reference. Certain plans may change characteristics of the data storage space described by the metadata, such as the number of partitions in the data storage space. In order to prevent complications that may arise from one cursor changing metadata while another cursor is using that same metadata, cursors whose actions may result in changing the metadata are placed on hold until all other cursors are finished using the shared metadata. However, this can result in a bottleneck effect, greatly reducing the efficiency of the database system.
These complications may be confronted by versioning the shared metadata, as described in U.S. application Pub. No. 20060004886, entitled “System for managing versions of cached metadata,” filed on May 13, 2005, which is also hereby incorporated by reference. When any characteristic of the data storage space described by the metadata changes, a new version of the metadata is created. Any cursors that were executing using the previous version of the metadata may continue to execute until those cursors have completed those cursors' plans; however, under such an approach, any cursor whose execution begins after the new version of the metadata is created must be recompiled to link to the new version of the metadata. This solution allows many cursors to run concurrently using the same metadata. However, a change in metadata invalidates cursors, inevitably requiring recompilation.
It is desirable to facilitate the changing of versioned metadata without invalidating cursors and requiring recompilation.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.